fix(deps): update dependency content-type to v3 - #8472

…tly (#8572)

Opened by Netliloop run [#392](https://netliloop.netlify.app/#/runs/392)
(security-scan), asked in
[Slack](https://slack.com/archives/C095D1JL480/p1791299459766719?thread_ts=1791298825.895999&cid=C095D1JL480)

### Why

- Renovate's [#8472](#8472)
(`content-type` v1 → v3) fails every build job: v3 is ESM-only, has no
default export, and `parse()` takes a header string instead of a request
object, so `src/utils/proxy.ts` and
`src/lib/functions/form-submissions-handler.ts` no longer compile. Its
sibling [#8377](#8377)
(`@types/content-type` v2) fails lint on its own because v2 is a stub
pointing at the package's bundled types.
- Both PRs have re-run and failed on every weekly rebase since July;
together they account for 64 + 40 failed integration jobs in the last
four weeks.

### What changed

- `content-type` goes to `^3.1.1` and `@types/content-type` is removed
(v3 ships its own types).
- The three call sites import `parse` by name and pass
`req.headers['content-type']`. The proxy already guarded on the header
being present; the form handler now defaults a missing header to `''`,
which parses to an empty type and falls through to neither form branch,
matching the proxy's guard.
- Behaviour change to know about: v3 `parse()` never throws on a string,
where v1 threw `TypeError` on a missing or malformed header. In
`src/utils/proxy.ts` that TypeError was an unhandled rejection that
crashed `netlify dev` on any POST with a malformed `Content-Type`; now
such a request proxies normally and gets the static server's 405 (the
new test covers this). The proxy only forwards form content types to the
form handler, so the handler's own `?? ''` is reached only when the
functions server is called directly; there a missing header now takes
the existing `Invalid Content-Type` warn-and-continue branch instead of
throwing.
- A `charset` parameter is passed through to `raw-body` exactly as
before: v1 also accepted any token value there, so `charset=bogus` still
ends in `raw-body`'s 415.
- All three call sites use the same `req.headers['content-type'] ?? ''`
idiom.
- Root `node_modules/content-type` is now the ESM-only v3; `npm ls
content-type` shows `express`, `body-parser`, `type-is` and verdaccio
each keep a nested v1/v2 copy, so no CommonJS `require('content-type')`
resolves to v3.
- Supersedes #8472 and #8377, which can be closed when this merges.

### How we verified

- `npm run build`, `npm run typecheck`, `npm run lint`: all exit 0 (on
#8472 the build fails with TS1192 and TS2345).
- `CI=true npm run test:unit`: 80 files passed.
- New integration test `should keep serving when a form submission
carries a malformed content type`: a POST with `Content-Type: not/a
valid; ;;` and a POST with no `Content-Type` at all (sent as a Buffer
body, since node-fetch adds `text/plain` to a string body) must each get
a 405 and the next GET a 200. On `main` it fails with `request to
http://localhost:33773/ failed, reason: socket hang up` because the
unhandled TypeError from `content-type@1` kills the dev server; on this
branch it passes (5.5 s).
- `CI=true npx vitest run --retry=3
tests/integration/commands/dev/dev-forms-and-redirects.test.ts` with the
new test included: 14 passed (14).
- End to end with the built CLI (`node bin/run.js dev --offline`)
against a fixture with a `submission-created` function, [commands and
output
here](https://netliloop.netlify.app/api/files/eyJrZXkiOiJldmlkZW5jZS8zOTIvZWZjYTE0YzgtYTFiMy00MzFjLWJmNjUtNzkzODA2ZGRlOTFiIiwibmFtZSI6ImNvbnRlbnQtdHlwZS12My1kZXYtZm9ybS1yZWNlaXB0cy50eHQiLCJ0eXBlIjoidGV4dC9wbGFpbiIsImV4cCI6MTgyMjgzNjk3OTIwNX0.f3ULpDp40grpAemeOoh55S3xXaZNBT5HVHJOjsr7JuE):
a urlencoded POST and a multipart POST with a file attachment both
reached the function with the parsed fields (200, function log shows the
fields); POSTs with no `Content-Type`, a malformed one, and
`application/json` were not treated as forms (405) and a GET afterwards
returned 200; `application/x-www-form-urlencoded; charset=UTF-8` still
matched.

### What is left to test

- Nothing. CI ran the full matrix on the final commit: 35 checks, all
green (unit on ubuntu/macOS/Windows, 8 integration shards, e2e, lint,
format, typecheck, verify-docs, package-size).

### Risk

`low`: one narrow code path in `netlify dev` (form-submission routing),
covered by the integration test and the end-to-end check above; a wrong
result shows immediately as a form POST not reaching the handler. No
Linear issue: a self-contained dependency fix the CLI team can merge
from this description.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Netliloop <netliloop@netlify.com>